perm filename SCU.TO[P,JRA] blob sn#579497 filedate 1981-04-11 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\\M1BASL30\M2BASI30\M3NGR25\M4NGR20
C00004 00003
C00012 00004	A Context for EECS 129
C00027 00005
C00029 00006	Discipline is Fascist
C00056 ENDMK
C⊗;
\\M1BASL30;\M2BASI30;\M3NGR25;\M4NGR20;
\F1\CJan 30,1980



Mark Davis, Editor-in-Chief
The Santa Clara 
Santa Clara  University


Dear Mark:

\JI am putting together an undergraduate special topics course
--EECS 129-- to be given in the spring term. It has the rather bizarre
purpose of getting Humanities, Sciences, Arts, and Engineering people
to talk to one another. It expects to show some that they don't know
as much about computing as they might think, and expects to show
others that they know more than they thought. As part of the "P. R."
compaign I'd like to write some articles for \F2The
Santa Clara\F1 about personal computing
and its relation to the University in particular and Society in general.
As slight background I'm enclosing a short blurb about the course --a draft,
and not for publication.


Is such a request  looked  on with favor?
\.
\←L\→S\←R\-L\/'2;\+L\→L

Yours sincerely,


John R. Allen. Lecturer
EECS Dept.
(408) 984-4358

\←S\→L
A Context for EECS 129

It is important to  view the "computing phenomenon"  in a broader  context
than just a technological, engineering  accomplishment.  While it is  true
that electronic computing machinery  is a recent  addition to the  world's
society, the ideas of computation --indeed even primitive realizations  of
these ideas-- have existed for many centuries.  It is therefore  important
to put "computing" in perspective with  the development of other arts  and
sciences. Unfortunately, contemporary computing classes either stress  the
technological aspects of the devices, or opt for the "warm-and-fuzzies" of
the "computer literacy" school which too often resorts to superficialities
of electronic  driver  education. EECS  129  is a  different  approach  to
"computer lunacy".

In our view, literacy in  a technical field is  comprised of at least  two
facets:  the aspect  of "form"  (or training), and  more importantly,  the
attention to the "substance" (or  educational) aspect. To us, literacy  in
"substance" implies that one  understands the fundamental principles  that
support the specific discipline.  Literacy  in "form" implies that one  is
conversant with the current technological tools.

Computing is a  puzzling phenomenon.   In this field,  technology has  the
typical physical aspect  of an engineering  discipline --the devices  that
carry out the computations.  However, one also finds a novelty not  shared
with other technologies:  there is a linguistic component to  computation.
One  expresses  requests  for  computation  as  "programs"  in  artificial
languages; these programs may be  as simple as numerical computations,  or
they may  be  as  complex  as programs  that  simulate  some  fragment  of
intelligent behavior.   In  either  case,  these  programs  represent  the
"literature" of the languages.   Unfortunately, the quality of  expression
in these computing languages typically  is quite poor. The  responsibility
must be shouldered by  both the language designer  and the programmer.   A
study of computing should discuss  this phenomenon of expressibility,  and
examine the issues of quality and style in computing languages --questions
too often ignored in computing classes.

Like the phenomenon of driving,  fluency in the computing domain  requires
experience with an instrument. Therefore a computing laboratory is  needed
to reinforce the concepts. As  with other experimental domains,  computing
experience should be gained  on the most  modern equipment possible.   The
computing device of the next decade is the "personal computer".

These personal computing devices  will soon supply the  power of the  last
decade's research machine.   The potential for  information processing  is
staggering,  not  just  in  terms   of  the  computing  power  but,   more
importantly, in  terms of  the novel  ways  that people  will be  able  to
interact with the machine.  In  this view of information interchange,  the
local user  will be  able to  interact with  other individuals  through  a
network.  In short, a computational community is formed, where the  "local
nodes" are highly interactive personal machines, perhaps with some  shared
devices; these  nodes are  linked  together to  larger machines  that  can
supply more processing power and perhaps  a more global view on the  local
communities.

EECS 129 will  involve an  Interactive Programming  Laboratory, that  will
utilize personal machines. In a  learning situation, these small  machines
arre often more effective than their larger counterparts, while  supplying
comparable software  experience.  The  small  machines can  offer  several
packages that are not available on the larger processors.  The hallmark of
these applications is their  highly interactive behavior, involving  rapid
manipulation of screen images to communicate results.

Several very elegant video  editing systems are  available; since a  large
portion of  computer  usage  involves  text-processing,  we  will  develop
familarity with such systems.

A business applications product  that is attracting substantial  interest,
VisiCalc, is only available on  micro-processors.  This system displays  a
segment of  a business  ledger in  such a  way that  whenever elements  of
related quantities are modified, one immediately sees all ramifications of
that action.   It is  an excellent  tool for  planning and  hypothesizing.
Believe it or  not, this  system represents an  application of  artificial
intelligence programming techniques.

Another work-reduction tool that utilizes both numerical and non-numerical
capabilities is an "algebraic manipulation system". These systems are able
to compute with  algebraic quantities much  like hand calculators  perform
with  numbers.   They  will  perform  complex  algebraic  simplifications,
symbolic differentiation and integration, as will as arithmetic operations
whose accuracy  is  not  restricted  by the  hardware  of  the  underlying
computer.

At a further level,  we will relate these  applications to the  techniques
that support their implementation.  This will involve experience with LISP
and Smalltalk.

Unfortunately, our resources will be limited for the first version of this
course. We'll be using a  collection of Z-80-based personal machines  that
support display manipulation in an adequate fashion.  Equipment donations,
anyone?  Though far from  optimal, we expect to  have facilities that  are
sufficient to demonstrate the important ingredients of personal computing.

Just as there is more to creative writing than knowing how to type, so too
we will not overlook  the fundamental ideas in  computing.  As with  other
fundamental  disciplines,   the   principal  computing   ideas   are   not
technological; they  are intellectual.   In the  computing sciences  these
principles are based on  simple information processing concepts  involving
the manipulation  of symbols.   These symbol  manipulation rules,  coupled
with the phenomenal speed of present-day computers, result in the powerful
machines that we now see.

The integrated  examination  of  these  facets  --  "substance"  for  mind
training, and "form" for fluency and literature-- can give content to  the
term "computer literacy", and form the basis for a solid understanding  of
modern computing and its relation to society.

Given this perspective on computing, it is now appropriate to discuss  the
issue of  computing's  impact  on  society.   Is  it  just  an  electronic
automobile, complete  with the  potential for  pollution?  Does  computing
represent  a  fundamental  cultural  shift,  threatening  to  replace  the
monolithic corporate  view  of the  civilized  western world  with  a  new
personal freedom? (My, that DOES  sound impressive.)  Is there life  after
artificial intelligence? One may even delve into the murky realms of: What
is a "good" programming language?  Arguing about programming languages  is
like arguing  religion:   mighty  discussions  but  few  converts  without
miracles.  There should be some minor miracles in computing this year.

In general, a  computing language is  a notation that  allows one  express
ideas in a from that can be executed by a computer.  Just as some  natural
languages  have  difficulty  expressing  some  concepts,  many  of   these
artificial  languages  suffer  from  restricted  expressibility.   A   few
languages exist that are worthy of study; they support creative expression
and experimentation with ideas.

The production  of any  artistic object  is typically  a long  an  arduous
process; the  creative  trail is  marked  with revisions,  reworking,  and
re-molding.  Unfortunately, many contemporary programming languages do not
support the  incremental  view of  creative  experimentation. To  a  large
extent, this failing is an historical anachronism, stemming from the  dark
ages  of  computing  when  computers  were  expensive,  ill-tempered,  and
awe-inspiring devices  to  be  approached  only  by  humble,  awe-inspired
individuals.   Times  have  changed,   but  the  mystique  remains;   more
unfortunately, languages based on this ancient view of computing have been
developed by expensive and ill-tempered  language designers who have  made
this historical failing into a virtue (if not a religion).

As a result, we  now have two distinct  language families: the  anarchists
and the fascists.  The  anachist's languages support interactive  creative
experimentation on computing machines; LISP, Smalltalk, and LOGO are  good
examples of this school. The fascists?  Well, discipline is good for  you,
and programming errors are results of faulty thinking, so the story  goes;
so be sure your program works before you approach the Wizard of OZ.   We'd
rather leave the Wizard to the Munchkins.

In future articles, we'll discuss a few more controversies --both real and
imaginary-- in computing.

				enhancements

fast floating point
 suggested mod: allow various amd 95xy boards to replace software

 time: two weeks

assembly language link
 	most of this is here from Cromemco LISP
 	needs a relocator program
time: one week 

port access
 suggested mod:
	View port as just another file of sink/source that can be opened, read and
	printed.
 technique: extend open

 time: three weeks

vectors
 suggested mod: add a new data type, with appropriate notation for
	reading and printing; add storage manager.
 time: three weeks

				extended enhancements

l-code
 suggested mod: 
	complete compiler for tlc, write interpreter
 time: one month

 video editor and debugger
Discipline is Fascist

warning: the  following  discussion  of Discipline  is  as  objective  and
even-handed as a Republican discussing Democratic political goals.

One may  argue  about language  features,  about syntax,  about  computing
equipment, and  about  operating  systems.  Unfortunately,  all  of  these
discussions involve disputations on effects,  not causes.  The root  issue
--that which  predisposes one  to argue  one side  or the  other of  these
questions-- involves one's perception of  the computer as an  intellectual
object:  do  you view  the computer  as an  automaton --dull,  blind,  and
obedient; or  do you  view the  computer as  the "stuff"  out of  which  a
creative medium may be constructed?

Of course, we don't have such arguments over an artist's paint brushes  or
typewriter:  the creativity resides in the artist; or over the  ubiquitous
mechanical device called the automobile:   a utilitarian tool; so what  is
it about the computer that could support a non-mechanistic interpretation?
At  the  extreme  end,  one  could  give  artificial  intelligence   based
arguments, showing that  one can  program machines to  perform many  tasks
attributed to  intelligent behavior  if they  were performed  by a  human;
however the pursuit of AI applications is a symptom, not a cause.  We need
not go that far to illuminate the distinctions:  a simple  word-processing
example will suffice.

Writing a letter

Consider  the  area  of  written  expression;  once  one  gets  past   the
"how-are-you-i-am-fine" stage of  letter writing, a  great deal of  mental
machinery must be brought to bear in expressing one's thoughts.   Creative
composition will involve  thinking, outlining,  expressing, and  revising.
Revision will span a wide range, from simple misspellings to major changes
in presentation. Our  traditional devices  of pencil and  paper have  been
sufficient  (when  augmented   with  an  eraser!)   to  support   creative
expression;  of  course,   we  should  relate   these  devices  to   their
predecessors--quill and earlier, chisel  that had no equivalent  "eraser".
One might argue  that "erasers"  are a bad  idea, diluting  the purity  of
expression that one MUST maintain in a non-erasable medium.  The  position
might be  sustained  by  arguing  that  one  should  think  precisely  and
accurately BEFORE beginning  the task;  and therefore all  errors are  the
result of sloppy preparation.  This view may have been sustainable in  the
days of  stone tablets,  but it's  hardly defensible  nowadays unless,  of
course, you believe you're infallible.

As I  recall this  sadistic view  of expression  is catered  to in  typing
schools. There, one is expected to  type documents perfectly, and in  case
of error,  destroy the  offending page  and begin  a-fresh; no  correction
fluid for these  whip wielders.   Of course, one  shouldn't expect  modern
thought to  make substantial  inroads in  an industry  whose weapon  --the
QWERTY keyboard--  is  based on  blind  obedience to  a  totally  outmoded
historical anachronism.  The typewriter keyboard layout was the result  of
a totally  mechanical  decision  whose  rationale  disappeared  eons  ago.
Interestingly enough,  one  can  lay  the  blame  for  outmoded  views  of
expression in programming to the same kind of neanderthalic thinking about
computation: anachronism become virtues. There  is a an interesting  19-th
century poem (sort of  the dual to  "for want of  a nail...") that  begins
with a cow crossing a field, making  a trail; then follows a person,  many
people, a road, a highway, etc. (sort of like Boston). A whole city builds
up around a  totally random, historical  accident. Unfortunately, much  in
computing has this same characteristic.

***compare with  typesetting machine  that  simply barfs  completed  copy.
compare the  traditional  publishing  hack:  write,  type,  revise,  loop.
keyboard,  typeset,  revise,   loop.   (in  the   second  phase   creative
modification is  very  highly discouraged  --edits  cost the  author  REAL
money)


So let us  assume that  humans make  errors in  creative composition,  and
instead of inflicting pain upon the unfortunates, let us hypothesize about
what kind of tools  could actually aid in  the corrective process.   Note,
the argument will be to improve tools, not to dilute the training required
for  their  effective  application.   The  creative  task  still  requires
mind-training; we only expect to minimize the distance between the  artist
and the expressive medium; we are not advocating "paint-by-numbers".

In the creative writing domain, one should cater:  for typing and spelling
errors --backspace and  correction; for rewording  --cutting and  pasting;
for document  scanning  --rapid and  random  page turning,  indexing,  and
tables of contents.


what makes a good editor: ****expand to e/bravo ****

⊗ what you see...

⊗ table of contents

⊗ pages

⊗ marking

⊗ cutting and pasting

⊗ fonts and formatting

The result: freedom of  expression, ego-less composition,  experimentation
with expression, better --not worse--  style.  The training can  emphasize
modes of expression, not  mechanical/technical details.  a better  tool--a
better product.

**view as instrument:  unobtrusive--second nature


Masochism is a PAIN!

Such systems sound interesting, useful, and  a real aid; how could  anyone
object to such  a tool?   Well, one  disciple of  discipline decries  such
devices, even to the point of  advocating the return to the stone  tablet.
In his judgement one should "practice" one's writing style by reverting to
the QWERTY-school:  whenever  one makes  an error,  expunge the  offending
page and begin  again.  This is  bad enough for  creative writing,  except
this prince of pain is a  major domo in the structured programming  school
and advocates  variants of  this masochism  as the  appropriate avenue  to
programming expertise.   One  should  not approach  the  machine  until  a
completed program  is in  hand; then  only with  appropriate humility  one
should beg answers from the electronic beast.  I assume that one must  not
make errors in typing in  the program; for then  one must destroy all  the
input and begin again.  The  argument is that this "disciplined  approach"
will cultivate clear-thinking, perfect programmers and thus goodness  will
come to the earth.

To my way  of thinking,  such a process  will lead  to terminal  insanity,
stilted programming style,  and generate  a breed  of mechanistic  fascist
coders.

To err is human

Clearly I exaggerate a bit;  just as the disciplined advocate  exaggerates
in his statements.  But  the essential lines are  drawn and are  believed.
"Discipline" views  mistakes  and  errors as  unnatural  acts;  the  other
school, that  I shall  call "Interaction",  views errors  and mistakes  as
natural unavoidable steps in the  process of learning. Whether the  domain
is writing  or  programming,  the artistic  tools  must  support  creative
expression; and those tools, if they are to be effective, must be  brought
to the creative experiment as soon as possible. Don't wait until the  last
moment to discover that the initial conception is faulty.

The essential ingredient in the Interaction view is that error is a  human
characteristic, in all but the most trivial tasks; and of course "trivial"
is a personal adjective; what  is trivial for you  may not be trivial  for
me. Triviality is  dependent on  experience, and one  gains experience  by
trial-and-error.

As a result, Interaction  believes that debugging is  a GOOD thing; it  is
called learning.   Understand "debugging";  support  it, teach  it.   More
deeply, there appears to be a fundamental difference of opinion about what
is the appropriate position of a computer wrt its user.

Discipline believes that  a machine  is a tool  that one  uses to  execute
problem solutions.   One uses  a brain  in the  exploratory, learning  and
experimentation phase; when the details are worked out one approaches  the
machine.  The  machine  therefore  is  not  a  tool  to  aid  one  in  the
design/understanding phase.  In this  sense therefore, Discipline views  a
computer only as a vehicle to  be applied in the business of  programming,
and only as a "last resort".  This  is a truly schizophrenic view: on  one
hand this attitude is the "typical" anti-machine/artistic view --"no  damn
machine  is   going  to   get  inside   my  head",   using  it   like   an
anti-technologist would  use  an  automobile.   On  the  other  hand,  the
approach one uses  outside the machine  arena --the structured  scientific
method-- is anti-artistic.

***give examples**

Interaction, on the  other hand,  views the  machine as  a resource  whose
power and aid is only limited by  what one has implementated at the  time.
The view  is that  one should  strive to  bring that  power to  bear on  a
problem as early as possible  in the planning/exploration phase. There  is
no fear of flying here; no fear  of The Machine. As a result,  Interactive
systems support  as  much  of the  "thought  crystallization"  process  as
possible.  You see it in the low-level interaction:

rapid display systems: the eye is an important input device; replace paper
with something better.

video editors: make the presentation of  material as easy as possible;  if
one makes mistakes, make it easy to repair them.

languages: ah! the crux of the matter.

languages for interaction:

Given that interactive editors are built to support creative  composition,
how should one approach the design of a programming language for a similar
effect?


⊗ incremental programming: execute partially specified programs

⊗ easy modification of program and data

⊗ easy correction of faulty computation w.o. restarting the world

⊗ problem-oriented presentation


The underlying ideas are directly related to the editing experience:   how
to support the program design and development process on the machine,  not
how to run the completed program.

Unfortunately,  the  "ultimate"  language  doesn't  exist.   In  fact  the
programming language  scene  is in  much  worse shape  than  the  "editing
language" scene.  Of course, the "language" for programming ideas requires
much higher levels of expressivity than that of text manipulation.

More unfortunately,  the  technologists  view of  programming  is  gaining
support: if Pascal wasn't bad enough, ADA is worse. I won't argue relative
"worseness" in  terms  of the  language  --would  you rather  hang  or  be
electro-"cuted"--, no,  the  fear and  loathing  is "political".   The  US
government sanction is sure to install this language and its philosophy in
every university and college in the US. --more about this later. There  is
another point to be made now about languages:

Note that in editing we reallly  don't talk about a "text language";  it's
important to have one, and  a bad one is  the pits! However the  important
ingredient here is the System  --the environment of quick interaction  and
displays-- that  makes  the  difference.  So  too  with  programming;  the
language is  only  one  part  of  the System.   We  are  talking  about  a
programming environment --an integrated package  that will make it  easier
to design programs.

though the ultimate language does not exist, we can exhibit some  examples
of languages/systems on the right track:

logo, education

smalltalk, simulation

lisp applications, ai, theory

ADA represents the wrong idea about the programming problem:  education is
wrong.  Programming is difficult and  demanding. One will not improve  the
problem by  supplying  tools that  will  monitor the  local  inanities  of
ill-trained minds.  Rather,  the education  of programmers  must be  taken
seriously: rigorous mind-training and access to the best/sharpest of tools
when they  have completed  their  apprenticeship.  No  mass  mechandising,
corner-cutting, assembly-line programming schools, please, PLEASE.  it's a
difficult task and belaboring programmers because their stupid and must be
protected from themselves is off-the-wall;  flush them sooner by  training
and education.

very important, since  the battle lines  will be drawn  on attitudes,  not
details.  claim Interaction is humanistic --AI is humanistic.

***relate to weizenbaum


programming languages compare correct-before-start view of writing

pascal what it represents.  lisp what it represents.


Why Discipline?  Clearly I am not the person to ask. However I have  heard
Wirth's reasons against  Interaction (and  I suspect  that Dijkstra  would
concur): he views Interactive programming as playing with toys, leading to
sloppy thinking,  and  a  "hacker  mentality".   Superficially,  I  agree;
fiddling without thinking is unforgiveable;  but placing the blame on  the
tools is short-sighted. The problem, again, is improper education.

Another facet that contributes is the well-defined mathematical nature  of
the tasks that Discipline tends to dwell upon. I definitely agree, that if
the problem is well-specified, then fiddling with interactive design is  a
mis-use of the tool. But what about the quest for a "new algorithm";  what
about problems that  don't have simple  closed-form representations;  what
about domains whose solutions are best (and perhaps ONLY) specifiable by a
program that simulates a particular behavior.

Finally one may trace contributory factors to early computing history (the
historical anachronism bug-a-boo again; cf QWERTY!). In the ancient  days,
machines were quite expensive, unreliable, and of very limited size.  Note
that  this  last  factor  --size--  is  finally  getting  flushed  out  of
programming methodology. The  size limitations have  been used to  justify
(a) assembly language and (b) "cute" tricks; methodological arguments have
been used effectively to remove these "tools" from the programmer's bag of
tricks; unfortunately we  still feel  the effects of  the "expensive"  and
"unreliability" arguments (though the  personal machines are beginning  to
drag on the "expensive" argument).

I feel that all  of these, now falacious,  reasons contributed heavily  to
reinforcing the early Discipline school. For in those days, one had to  be
very careful of  machine time;  MTBF on a  IBM704 (very  slow 8080  --32K,
36-bit words) was about 30  minutes, time was very expensive,  programming
was done batch,  decks were  punched, and  turn-around on  jobs was  often
overnight; finally, programmer's were  relatively cheap.  (one might  also
note that the majority of  these computer jobs involved getting  numerical
answers from the execution of well-specified numerical algorithms)

historical anachronism: basic

historical anachronism: lisp

compare programming with driving

⊗ pascal: plan+ return to starting position at failure

⊗ lisp: piloting+in course correction

An analogy: Consider the problem of driving from Santa Clara to Berkeley.


The QWERTY school of driving

Consider a Discipline  driver: Make  a plan,  detailing all  of the  steps
(stop lights, turns, and conditions  that one expects). Proceed to  follow
plan.  If an unexpected situation  occurs (e.g.  detour), return home  and
replan.

Consider an  Interaction  driver: Make  a  plan, etc.   If  an  unexpected
situation  occurs,  modify  plan   (debug  it!!)   and  continue,   unless
impossible.  compare interactive programming development.

The QWERT School  of programming

compare compile, run, edit cycle.


Which is more  "human-oriented"; which holds  more promise; which  expects
more intelligence from its user?  Why do AI people opt for Interaction? In
fact J McCarthy is  one of the founders  of the time-sharing ideas  (whose
purpose, by  the way,  was  to make  "personal computing"  available  long
before it was economically feasible-- not just to allow more batch hacking
--RJE crap-- on existing machines)


****how to talk about debuggin of ideas****

**cf polya***

**cf sussman, logo

**cf perlis' remark

  there is a place for disciipline (there is a place for transcription)
  cf typesetting

  the problem: how to keep the exploratory version from being prepetuated?
  throw-away programmin/ ego-less composition

  the solution: to make the first pass so easy that one WILL throw it away
  and do it over.

** technological limitations have caused us to 
severly limit our expectations.  cf kids on logo/smalltalk.


**cf a text processing machine that is "smart" in the sense of correcting
grammar, punctuation, and syntax, for a creative author. how far would 
that go (about six feet --out the window!)